Clock synchronization in a communication network is the means by which a clock signal is generated or derived and distributed through the network and its individual nodes for the purpose of ensuring synchronized network operation. Herein, clocking refers to a process whereby a timing signal is used by a physical interface of a network device to put data on a transmission media as well as extract data from the transmission media. In other words, clocking at a physical interface of a network device controls the speed at which data is transmitted on a physical connection.
Two main performance degradation issues come into play when clocks at a transmitter and a receiver are not synchronized. First, if the physical interfaces along a connection are not synchronized (i.e., not driven by a clocking signal of identical frequency), data can be lost due to buffer overflow or underflow, resulting in periodic line errors. When the physical interfaces are synchronized, then, within a given time window, the same amount of data is transmitted or forwarded at every point in the connection. Second, imperfections in clock synchronization can lead to observable defects on an end service such as bit errors due to alignment jitter when interworking with a plesiochronous digital hierarchy (PDH) or a synchronous digital hierarchy (SDH) network, or frame slips when interworking with a public switched telephone network (PSTN) or an integrated service digital network (ISDN).
The widespread acceptance of packet-switched technologies such as IP/Ethernet and recent advances in high-speed switching and forwarding, and quality of service (QoS) management has made it possible to build converged voice and data networks. By using IP/Ethernet, various services such as voice, video, and data can be multiplexed, switched, and transported together under a universal format. Full integration will likely result in simpler and more efficient network and service administration and management.
However, the demand for high quality real-time multimedia applications requiring strict clock synchronization properties, such as digital television and voice processing, is on the increase. Clock synchronization is an important design consideration in time division multiplexing (TDM) networks, and in packet networks carrying TDM voice or video traffic. TDM data, for instance, must be received and transmitted at the same rate at every hop in a connection. Packet networks that carry pure data traffic that do not require an end-to-end timing relationship (e.g., TCP/IP traffic) need not worry as much about clock quality. IP/Ethernet networks offer essentially an asynchronous transmission service, thus making the synchronization needs of real-time applications difficult to meet in these networks. Unlike packet switched networks, circuit switched networks (which typically use TDM) are engineered to minimize switching and transmission jitter that degrade the quality of voice and data services. Switching and transmission jitter is minimized by synchronizing input and output links at every node via, for example, pulse stuffing techniques.
To interwork with a circuit switched network whose services are pre-dominantly time-sensitive, a packet (e.g., IP) network must essentially behave as a transparent “link” in an end-to-end connection. This transparent inclusion of a packet network in an end-to-end path of a connection that carries circuit-switched time sensitive services is referred to as “circuit emulation” on the packet network. Circuit emulation services (CES) allow a network operator to seamlessly migrate network core infrastructure from circuit switched to packet switched, while preserving the legacy circuit switched end equipment.
A good clock synchronization scheme is essential for the successful deployment of CES. Packet networks that transport voice, video, and/or telephony services also require an end-to-end timing relationship and therefore must have well-designed network clock synchronization mechanisms. Lack of synchronization traceability between TDM equipment interconnected over a packet network may result in frame or byte slips which can affect data integrity. Thus, critical to performance, transmission, data integrity, and ultimately quality of service of any network where TDM and real-time services are supported, is the manner by which the various network equipment derive and maintain synchronization.
There are three broad categories of clock synchronization in a packet network. First, in a network synchronous approach, all devices are clocked from a common clock or primary reference source (PRS). This offers the best clock quality, but can be expensive since the network requires a PRS and a clock distribution service, except in toll-bypass networks where there is a PRS at each end of the packet network. The regulatory constraints may also make this approach impractical.
Second, a transmitter and a receiver may be clocked independently. That is, usually the clocks at the transmitter and receiver will have the same nominal frequency but differ in their amounts of random variation from the nominal values (e.g., in parts per million, ppm). In this case, the transmitter sends data out with a locally generated, independent clock and any difference that might occur between the receiver and transmitter clocks is taken up with a “slip buffer” which can insert or delete bits from the data stream if the need arises. This technique cannot guarantee the bit level integrity of the data unless the transmitter and receiver clocks are synchronized with each other.
Third, a receiver may derive an estimate of the transmitter clock from the received data stream. This is commonly done using a phase-locked loop (PLL) that slaves the receiver clock to a transmitter clock. The PLL is able to process transmitted clock samples encoded within the data stream, or process data arrival patterns to generate a timing signal for the receiver. The purpose of the PLL is to estimate and compensate for the frequency drift occurring between the oscillators of the transmitter clock and the receiver clock. In operation, the presence of transmission jitter affects the performance of the clock estimation/compensation process, making the transmitter clock appear faster or slower than it actually is, and ultimately, causing the propagation of some residual jitter to the receiver clock signal. The presence of even a modest amount of jitter makes the clock recovery problem difficult. The design of the PLL must ensure that clock impairments are within acceptable limits for the intended applications.
In the timestamp-based scheme, the transmitter sends an explicit time indication or timestamp (in a packet with or without user data) to the receiver so that it can synchronize its local clock to that of the transmitter. Since no common network clock is used, the receiver relies on locking the receiver clock to the arrival of the timestamp patterns. The timestamp method is analogous to the periodic insertion of synchronizing patterns into the bit stream at the transmitter. At the receiver, the synchronizing patterns are detected and used to generate a reference signal for a PLL.
In real-time data transmission, for example, to synchronize non-periodically transmitted data (e.g., possibly due to data compression or silence suppression as in voice traffic), the timestamp method uses a monotonic clock. This monotonic clock is usually incremented in time units that are smaller than the smallest block size of the data stream. The initial monotonic clock value can be random.
Referring to FIG. 1, there is shown a communication system 10 which implements a clock synchronization scheme based upon the timestamp method. The communication system 10 comprises a transmitter 12, a receiver 14, and a network 16 through which packets 17 are sent from the transmitter 12 to the receiver 14. The transmitter 12 comprises a network adaptor 18 and a transmitter clock 20. The transmitter clock 20 comprises an oscillator 22 and a first pulse counter 24. The receiver 14 comprises a jitter buffer 26 and a receiver clock 28. The receiver clock 28 comprises a phase-locked loop (PLL) 30 having a differencing element 32, a loop filter 34, and a local clock 36. The local clock 36 comprises a voltage controlled oscillator (VCO) (or digitally controlled oscillator (DCO)) 38 and a second pulse counter 40.
The clock synchronization scheme implemented in the communication system 10 allows multiple receivers (e.g., in a broadcast or point-to-multipoint communication scenario) to synchronize their clocks to that of the transmitter clock generated by the oscillator 22. The oscillator 22 issues periodic pulses that are input to the first pulse counter 24. The oscillator 22 has a frequency that is the inverse of the interval between consecutive pulses (i.e., the oscillator period). The output of the first pulse counter 24 represents the transmitter clock signal and is incremented by a fixed amount at each pulse. Samples of transmitter clock are communicated to the receiver 14 in packets 17 as timestamps.
At the receiver 14, the PLL 30 uses the timestamps (which constitute the PLL reference signal) to synchronize with the transmitter clock. At the differencing element 32, an error signal is generated from the difference between the reference signal (i.e., the timestamps) and a feedback signal from the second pulse counter 40. The error signal is passed on to the loop filter 34, which is responsible for eliminating possible jitter and noise in received input signals. The VCO (or DCO) 38, which typically has a center frequency, oscillates at a frequency which is determined by an output signal of the loop filter 34.
Ideally, there is a constant delay between the transmitter 12 and the receiver 14, and the timestamp values arriving at the receiver 14 are all consistent. However, this is not the case in packet networks. Rather, delay variation between the transmitter 12 and the receiver 14 occurs in packet networks. This delay variation complicates the clock synchronization problem because it effectively introduces network jitter to the timestamps that are generated at the transmitter 12 and received at the receiver 14.
There are three main contributors to jitter seen at the receiver 14. The first contributor is due to frequency drift between the clocks in the transmitter 12 and the receiver 14. This contribution is usually small compared to the other two contributors. The second contributor is due to packetization at the transmitter 12, which may displace timestamp values within a packet stream. Lastly, the third contributor is due to packet multiplexing and variations in queuing delays in network switches.
If a significant amount of jitter is passed on to the recovered clock, its quality may degrade (i.e., the PLL 30 may not provide a sufficiently stable clock signal). As a result, the PLL 30 must perform filtering in order to correctly estimate the transmitter clock. However, the design of the PLL 30 must be such that its filtering capabilities do not slow the responsiveness of the PLL 30 and increase the amount of time it requires to estimate the transmitter clock. This is because slow PLL responsiveness and increased transmitter clock estimation time affect the maximum phase error between the transmitter time-line and the receiver time-line which in turn increases the amount of memory in the receiver 14 that must be allocated to hold unread data. The receive (jitter) buffer 26 also has to be at least the size of the jitter amplitude (statistical bound) that the receiver 14 wants to absorb. Otherwise, packets that experience more delay than the maximum jitter amplitude are discarded.
Unfortunately, in addition to transmission jitter, poor oscillator quality, temperature change, and other unaccountable perturbations in the system affect the performance of the clock estimation/compensation process, making the transmitter clock appear faster or slower than it actually is.
In view of the foregoing, it would be desirable to provide a technique for maintaining clock synchronization during periods of degraded synchronization.